contents

GitHub Actions(깃허브 액션) 는 GitHub에 직접 내장된 강력하고 유연한 자동화 및 CI/CD(지속적 통합/지속적 전달) 플랫폼입니다. 이를 통해 푸시(push), 풀 리퀘스트(pull request), 새로운 이슈 생성 등 GitHub 리포지토리 내의 이벤트에 반응하여 소프트웨어 개발 워크플로우를 자동화할 수 있습니다.

종종 별도의 시스템인 전통적인 CI/CD 도구와 달리, GitHub Actions는 GitHub에서의 개발자 경험에 네이티브하게 통합되어 있습니다.

GitHub Actions의 역할 (단순한 CI/CD를 넘어서)

가장 일반적인 용도는 CI/CD이지만, GitHub Actions는 범용 자동화 플랫폼입니다. 다음과 같은 작업에 사용할 수 있습니다.

• 코드 빌드, 테스트, 배포 (고전적인 CI/CD 사용 사례)
• 이슈 및 풀 리퀘스트 관리 자동화 (예: 자동으로 레이블 추가 또는 리뷰어 할당)
• 이벤트 발생 시 슬랙이나 다른 서비스로 알림 보내기
• npm이나 Docker Hub와 같은 레지스트리에 패키지 게시하기
• 예약된 Job을 실행하여 유지보수 수행 또는 보고서 생성하기

핵심 개념: 빌딩 블록 🤖

GitHub Actions를 이해하려면 다섯 가지 핵심 구성 요소를 알아야 합니다.

1. 워크플로우 (Workflow): 사용자가 정의하는 자동화된 프로세스입니다. 각 워크플로우는 하나 이상의 Job으로 구성되며 이벤트에 의해 트리거됩니다. 워크플로우는 리포지토리의 .github/workflows 디렉터리 내 YAML 파일에 정의됩니다.
2. 이벤트 (Event): 워크플로우 실행을 트리거하는 리포지토리 내의 특정 활동입니다. 예시는 다음과 같습니다.
   • push: 코드가 브랜치에 푸시될 때.
   • pull_request: 풀 리퀘스트가 생성되거나 업데이트될 때.
   • schedule: 예약된 시간에 실행될 때 (cron job처럼).
   • workflow_dispatch: GitHub UI에서 수동으로 트리거할 때.
3. Job (작업): 동일한 Runner에서 실행되는 Step들의 집합입니다. 기본적으로 워크플로우의 Job들은 병렬로 실행됩니다. Job들이 서로 의존하여 순차적으로 실행되도록 설정할 수도 있습니다.
4. Runner (러너): 워크플로우 Job을 실행하는 서버입니다. GitHub는 두 가지 유형을 제공합니다.
   • GitHub 호스팅 Runner: GitHub가 관리하는 새로 프로비저닝된 가상 머신(Ubuntu, Windows 또는 macOS)입니다. 사용하기 쉽지만 사용량에 제한이 있습니다.
   • 자체 호스팅 Runner: 사용자가 직접 관리하고 호스팅하는 머신(클라우드 또는 온프레미스)입니다. 하드웨어, 운영 체제, 소프트웨어 도구에 대한 더 많은 제어권을 가집니다.
5. Step (단계): Job 내에서 명령어 또는 Action을 실행할 수 있는 개별 작업입니다. Job 내의 Step들은 순서대로 실행됩니다.
6. Action (액션) 📦: 가장 강력한 개념입니다. Action은 복잡하지만 일반적인 작업을 수행하는 재사용 가능한 코드 조각입니다. 워크플로우에서 호출할 수 있는 함수나 라이브러리처럼 생각할 수 있습니다. GitHub Marketplace에서 코드를 체크아웃하는 actions/checkout이나 Node.js 환경을 설정하는 actions/setup-node와 같은 수천 개의 Action을 찾을 수 있습니다.

워크플로우 파일: 예시

GitHub Actions의 모든 것은 YAML 파일에 정의됩니다. 다음은 코드가 main 브랜치에 푸시될 때 실행되는 Node.js 프로젝트의 간단한 CI 워크플로우에 대한 상세 예시입니다.

파일 위치: .github/workflows/ci.yml

# Actions 탭에 표시될 워크플로우의 이름
name: Node.js CI

# 이 워크플로우를 트리거하는 이벤트
on:
  push:
    branches: [ "main" ] # main 브랜치로의 푸시에만 실행
  pull_request:
    branches: [ "main" ] # main을 대상으로 하는 풀 리퀘스트에도 실행

# 워크플로우 실행은 하나 이상의 Job으로 구성됨
jobs:
  # 이 Job의 고유 ID
  build:
    # Job이 실행될 Runner의 유형
    runs-on: ubuntu-latest

    # 여러 버전에 걸쳐 Job을 실행하기 위한 전략
    strategy:
      matrix:
        node-version: [18.x, 20.x] # 이 Job을 각 버전에 대해 한 번씩, 총 두 번 실행

    # Job의 일부로 실행될 작업 시퀀스
    steps:
      # 1단계: 미리 만들어진 Action을 사용하여 리포지토리 코드를 체크아웃
      - name: Checkout repository
        uses: actions/checkout@v4

      # 2단계: 다른 Action을 사용하여 지정된 Node.js 버전을 설정
      - name: Use Node.js $NaN
        uses: actions/setup-node@v4
        with:
          node-version: $NaN

      # 3단계: 셸 명령어를 실행하여 의존성을 설치하고 테스트를 실행
      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

주요 특징 및 장점

• GitHub와의 깊은 통합: 내장되어 있습니다. 풀 리퀘스트 상태, 로그, 아티팩트가 모두 GitHub UI에서 직접 보이므로 매끄러운 경험을 제공합니다.
• Marketplace: 커뮤니티와 공식적으로 지원되는 방대한 Action 라이브러리 덕분에 바퀴를 다시 발명할 필요가 없습니다.
• 매트릭스 빌드: 예시에서 보듯이, 여러 버전의 언어, 운영 체제 또는 기타 매개변수에 걸쳐 동일한 Job을 쉽게 실행할 수 있습니다. 이는 호환성 테스트에 매우 강력합니다.
• 넉넉한 무료 플랜: GitHub는 공개 및 비공개 리포지토리에 대해 상당한 양의 무료 빌드 시간을 제공하여 개인 및 소규모 팀이 쉽게 접근할 수 있습니다.
• YAML 설정: 모든 워크플로우는 "코드"(.yml 파일)이므로, 버전 관리가 가능하고, 검토할 수 있으며, 재사용할 수 있습니다.

GitHub Actions vs. Jenkins

references